👣 Microsoft анонсировала радикальное улучшение производительности TypeScript за счет новой нативной реализации компилятора, написанной на Go.

Самое главное:

▪ В 10 раз (!) быстрее компиляция, в 2 раза меньше памяти просит;
▪ На видео как раз тест нового компилятора: 0.63 секунды против 3.35 на старом;
▪ Проект пилят с августа 2024, готово уже 80%;

Полный переход займёт годы 😢;
▪ В версии на Go не работает «манкипатчинг», что сделает API TypeScript более безопасным;
⚫ Планируют интеграцию с LLM (надеюсь, локальными);
⚫ Полный переход на TypeScript-Go не отменяет поддержку старой версии;
⚫ Кодовая база TypeScript в Go расходится с оригиналом, так что некоторые фичи (вроде JSDoc и JSX) могут полететь.


Проект в разработке с августа 2024, готово уже 80%.


Полное интервью с апдейтами тут глянуть на YouTube

▪Github: https://github.com/microsoft/typescript-go
▪Microsoft blog: https://devblogs.microsoft.com/typescript/typescript-native-port/

#dotnet #golang #programming #typescript #webdev

@golang_google

👣 bubbletea — фреймворк на Go для создания интерактивных текстовых пользовательских интерфейсов (TUI)!

🌟 Bubble Tea основан на архитектуре Model-Update-View (MUV), вдохновлённой Elm, что позволяет писать чистый, модульный и поддерживаемый код. Этот фреймворк идеально подходит для создания консольных приложений, игр, инструментов визуализации данных и других текстовых интерфейсов.

🔐 Лицензия: MIT

🖥 Github

@golang_interview

👣 "Benchmarking: What you cannot miss in Go 1.24" статья, которая посвящена ключевым моментам бенчмаркинга в новой версии Go 1.24.

📌 Основная cуть:
    • Рассматриваются лучшие практики и новые возможности для написания и проведения бенчмарков в Go 1.24.
    • Автор делится опытом, демонстрирует примеры, объясняет, как правильно измерять производительность и избегать распространённых ошибок.

📌 Польза для разработчиков:
    • Помогает оптимизировать приложения на Go, выявляя узкие места в производительности.
    • Раскрывает улучшения и особенности новой версии, что важно для точного и эффективного тестирования кода.
    • Предоставляет практические рекомендации, которые можно сразу применять в реальных проектах.

Эта статья будет особенно полезна тем, кто стремится повысить производительность своих приложений и глубже разобраться в нюансах бенчмаркинга на Go.

📌 Читать

@golang_google

👣 ОAtomixDB — это инновационный инструмент для управления данными, созданный разработчиком Sahilb315 на GitHub.

▪ Атомарность операций: гарантирует, что каждая транзакция выполняется полностью или не выполняется вовсе, что существенно снижает риск ошибок и потери данных.
▪ Простота интеграции: интуитивно понятный API позволяет легко внедрять AtomixDB в проекты разного масштаба, от небольших приложений до распределённых систем.
▪ Масштабируемость: инструмент спроектирован с учётом современных требований к производительности, что делает его подходящим для высоконагруженных систем.
▪ Открытый исходный код: вы можете свободно изучать, модифицировать и расширять функциональность AtomixDB под специфические нужды вашего проекта.

Если вы ищете надёжное, эффективное и гибкое решение для управления данными с гарантией целостности, AtomixDB — отличный выбор для реализации современных приложений.

📌 Github

👣 Новый пост официального блога Go рассказывает о том, как концепция «core types», введённая вместе с обобщениями в Go 1.18 для упрощения работы с операндами типа-параметров, оказалась излишне сложной. Основные моменты таковы:

Истоки и проблемы: В Go 1.18 появились типовые параметры и ограничения, которые требовали введения core types для унификации операций над обобщёнными типами. Однако это добавило сложности как в спецификацию языка, так и в понимание работы некоторых операций (например, срезов и индексирования) даже для негeneric-кода.

Изменения в Go 1.25: В предстоящем релизе Go 1.25 концепция core types была полностью удалена из спецификации. Вместо этого теперь используются более явные и понятные правила, что упрощает изучение языка и повышает ясность спецификации без изменения поведения существующего кода.

Таким образом, пост подчёркивает, что отказ от core types делает спецификацию Go проще и понятнее, одновременно открывая возможности для будущих улучшений языка.

🔗 Читать

@Golang_google

👣 «Golang на PlayStation 2» очень интересный кей, в котором автор делится опытом запуска кода на консоли PlayStation 2 с использованием Go.

Поскольку стандартный компилятор Go не поддерживает PS2 и требует наличия операционной системы, автор использует TinyGo — компилятор для встраиваемых систем, который преобразует Go-код в LLVM IR, а затем в машинный код для целевой платформы.​


Основные трудности связаны с архитектурой процессора PS2, известного как Emotion Engine, основанного на MIPS R5900.

Этот процессор поддерживает инструкции MIPS-III и MIPS-IV с некоторыми особенностями и отсутствием определённых функций. Автор использует SDK ps2dev, предоставляющий библиотеки для графики, ввода-вывода и других операций, однако сталкивается с необходимостью обеспечения совместимости с ABI N32 и другими специфическими требованиями.​
Ricardo

Проект находится в стадии разработки, и планируется дальнейшая работа над поддержкой специфичных для PS2 функций, обработкой чисел с плавающей запятой и улучшением совместимости с LLVM.​

📌 Читать

👣 “Common Go Performance Patterns” — распространённые паттерны производительности в Go.

В ней рассматриваются ключевые техники, сгруппированные в четыре основные категории:​


1. Управление памятью и эффективность:

- Pooling объектов: Повторное использование объектов для снижения нагрузки на сборщик мусора и уменьшения накладных расходов на выделение памяти.​

- Предварительное выделение памяти: Заранее задавать емкость срезов и карт для предотвращения дорогостоящих операций изменения размера.​

- Выравнивание полей структур: Оптимизация расположения полей в структурах для минимизации заполнения и улучшения локальности данных.​

- Избегание упаковки интерфейсов: Предотвращение скрытых выделений памяти путем отказа от ненужных преобразований типов к интерфейсам.​


- Техники нулевого копирования: Минимизация копирования данных с использованием срезов и буферов.​

- Эффективность памяти и сборщик мусора Go: Снижение нагрузки на сборщик мусора путем минимизации использования кучи и повторного использования памяти.​

- Стековые выделения и анализ ускользания: Использование анализа ускользания для размещения значений в стеке, когда это возможно.​

2. Конкурентность и синхронизация:

Пулы рабочих горутин: Контроль уровня конкурентности с помощью пулов фиксированного размера для ограничения использования ресурсов.​

Атомарные операции и примитивы синхронизации: Использование атомарных операций или легковесных блокировок для управления общим состоянием.​

Ленивая инициализация: Отсрочка выполнения затратных операций до момента, когда они действительно необходимы.​

Совместное использование неизменяемых данных: Безопасное совместное использование данных между горутинами без блокировок путем обеспечения их неизменяемости.​
goperf.dev

Эффективное управление контекстом: Использование пакета context для передачи тайм-аутов и сигналов отмены между горутинами.​


3. Оптимизация ввода/вывода и пропускная способность:

Эффективное буферизирование: Использование буферизованных читателей/писателей для минимизации вызовов ввода/вывода.​

Группировка операций: Объединение нескольких мелких операций для уменьшения количества раунд-трипов и повышения пропускной способности.​

4. Оптимизация на уровне компилятора и настройка:

Использование флагов оптимизации компилятора: Применение флагов сборки, таких как -gcflags и -ldflags, для настройки производительности.​

Стековые выделения и анализ ускользания: Анализ того, какие значения переходят в кучу, чтобы помочь компилятору оптимизировать размещение памяти.​
goperf.dev

Эти техники помогают разработчикам Go создавать более эффективные и производительные приложения, снижая задержки, улучшая использование памяти и повышая эффективность конкурентных операций.

🔗 Читать

@golang_books

👣 "Leak and Seek: A Go Runtime Mystery" на сайте Cyolo описывает расследование команды разработчиков, направленное на выявление и устранение утечки памяти в приложении, написанном на языке программирования Go.

Несмотря на то, что Go использует сборку мусора для управления памятью, команда столкнулась с необычной утечкой, связанной с объектами SqliteRows, SqliteStmt и SqliteConn.​


Основные моменты статьи:
- Начало расследования: После сообщений от нескольких крупных клиентов о значительных проблемах с производительностью, команда начала собирать профили памяти и горутин, чтобы определить источник утечки.​

- Исключение горутин: Анализ показал отсутствие накопления активных горутин, что позволило исключить утечки, связанные с ними.​

- Обнаружение проблемы в драйвере SQLite3: График распределения объектов в памяти указал на утечку, связанную с драйвером SQLite3, используемым в приложении.​

- Анализ финализаторов: Команда обнаружила, что недавно добавленный финализатор для SqliteRows может вызывать блокировку единственной горутины, ответственной за выполнение всех финализаторов в Go. Это приводило к накоплению неосвобожденных объектов и, как следствие, к утечке памяти.​
Cyolo

- Использование инструмента goref: Для дальнейшего анализа команда применила инструмент goref, позволяющий картировать граф ссылок объектов в куче, что подтвердило отсутствие живых объектов, удерживающих утекшие данные, и указало на проблему в самом рантайме Go.​

- Обнаружение блокировки в go-smb2: В конечном итоге было выявлено, что блокировка в пакете go-smb2 приводила к остановке горутины финализатора, что вызывало утечку памяти.​
Cyolo

- Результаты и рекомендации: Команда сообщила о найденной проблеме сообществу Go, предложив улучшить документацию по финализаторам и внедрить метрики для обнаружения медленных или заблокированных очередей финализаторов.​

Статья подчеркивает важность тщательного анализа и командной работы при решении сложных проблем в программировании, а также необходимость понимания внутренних механизмов используемого языка и его инструментов.

📌 Читать

👣 «Карты конкурентности в Go» автор предлагает оригинальный подход к обучению конкурентному программированию в Go, используя метафору карточной игры.

Каждая "карта" представляет собой ключевую концепцию или инструмент, связанный с конкурентностью в Go.​

🃏 Основные "карты" конкурентности в Go
Горутины (goroutines): Лёгкие потоки, позволяющие выполнять функции параллельно.​

Каналы (channels): Средство коммуникации между горутинами, обеспечивающее безопасный обмен данными.​

Селекторы (select): Позволяют горутине ждать нескольких операций с каналами одновременно.​

Мьютексы (mutexes): Механизм синхронизации, предотвращающий одновременный доступ к общим ресурсам.​

Пулы воркеров (worker pools): Шаблон для управления группой горутин, выполняющих задачи из общей очереди.​

Автор подчеркивает важность понимания этих концепций для эффективного использования конкурентности в Go. Он также обсуждает типичные ошибки и подводные камни, такие как гонки данных и блокировки, и предлагает стратегии их избегания.​

Статья рекомендуется для разработчиков, стремящихся углубить свои знания в области конкурентного программирования на Go.

▪ Читать

👣 Как одной Go‑службе легко выдержать 200000 RPS на одной машине

В свежей статье Никиты Бурова разбирается практический кейс: без шардирования, без десятков реплик и без магии облака — всего за счёт правильных оптимизаций Go‑сервис на одном MacBook Pro M3 достигает 200000 запросов в секунду с медианным P50 < 1 мс. Вот главные приёмы:

1⃣ Сводим работу «горячего» пути к минимуму
- Статический преподготовленный фид — из памяти, без БД/API.
- Ноль аллокаций — никаких new/make в горячем пути.

2⃣ net/http → fasthttp
- Быстрее TCP, буферы, заголовки.
- ×8–10 прирост RPS.

3⃣ Pool объектов + явный сброс
- sync.Pool для структур.
- Отказ от defer.

4⃣ Tюнинг GOMAXPROCS + GOGC
- GOMAXPROCS= ядра.
- GOGC=200–300.

5⃣ Профилирование pprof benchstat

Результат: один инстанс держит 200000 RPS с P50 < 1мс и P99 < 2мс.

🔗 Полная статья: https://medium.com/@nikitaburov/how-to-easily-handle-200k-rps-with-golang-8b62967a01dd

👣 Без излишеств: изящная архитектура Go‑проекта

Как часто вы ловите себя на вопросе: «Как лучше организовать структуру репозитория Go‑проекта?» В беседах на Gopher Slack и телеграм чатах подобные вопросы возникают вновь и вновь.

Впрочем, в сети так много устаревших или чрезмерно запутанных гайдов, что порой сложно найти по-настоящему удручающе простое решение.

Одна из краеугольных идей философии Go — стремление к максимальной простоте.

Начните с малого: пишите функциональный код, не создавая сложную иерархию каталогов до тех пор, пока в этом нет реальной нужды.

Что говорит официальная документация
На сайте go.dev можно найти рекомендации от авторов языка:

«В больших проектах или монолитных приложениях бывает полезно вынести часть функциональности в поддерживающие пакеты, помещая их в каталог internal. Код внутри internal/ недоступен для стороннего импорта, что позволяет нам без опасений рефакторить API и перестраивать структуру».

Заметьте, слова — «больших» и «бывает» — подчёркнуты не случайно.

Большинству небольших или средних проектов вовсе не нужен internal/: достаточно просто не экспортировать те функции, которые не предназначены для внешнего использования.

Идея «сначала создайте internal/, потом думайте о дизайне» кажется чрезмерной. Но зачастую, разумнее сперва выпустить полезный функционал, а уже потом, по мере роста проекта, скорректировать структуру.

Что не стоит копировать вслепую
Наверняка вы слышали о репозитории «golang-standards/project-layout», который многие называют «стандартом». На деле это скорее набор идей, вокруг которых бурно дискутируют, нежели непреложное правило.

Не позволяйте чужим конвенциям диктовать ваш рабочий процесс: возможность импортировать из internal/ или раскладывать всё по папкам cmd/, pkg/ и т. д. — далеко не обязательный шаблон для каждого проекта.

Рекомендации из практики
Пакет main
Если ваш проект — это одно единственное приложение, вполне логично держать main.go в корне. Команда

go install github.com/you/project@latest

сработает без лишних телодвижений. Если же вы развиваете и библиотеку, и отдельный исполняемый файл, можно вынести main в подпапку (например, app/) — но не более того.

Каталог internal/
Применяйте его лишь в том случае, когда ваш код действительно потребляют десятки сторонних проектов. Для большинства библиотек и приложений довольно размещать «внутренние» пакеты там, где они логически принадлежат, просто не экспортируя нежелательные символы.

Каталог pkg/
Когда-то pkg/ помогал отделять библиотеки от «прочего» кода. Теперь, после появления internal/, он утратил былую нужность. Любой пакет из pkg/ можно без труда перенести в корень, не нарушив логику проекта.

Утилиты util/, common/, shared/
«Утильные» каталоги зачастую превращаются в свалку беспорядочных функций. Лучше дать такому набору ясное название или разместить функции непосредственно рядом с их точкой использования.

Не множьте пакеты без надобности
В Go несколько файлов в одном пакете — не проблема. Не выделяйте новый пакет ради нескольких строк кода: это усложняет навигацию и повышает риск непреднамеренных циклических зависимостей.

Примеры
🔸 github.com/fortio/ — сервер, библиотеки и CLI в одном репозитории

🔸 github.com/fortio/proxy — отдельный HTTP‑прокси

🔸 github.com/fortio/multicurl — консольный инструмент

🔸 github.com/fortio/terminal — два пакета + CLI

🔸 github.com/grol-io/grol — Go с WebAssembly

Сосредоточтесь на действительно важных вещах — написании кода.